Subject: How to support non-LAN DLCs

From: "almost, but not quite, entirely unlike tea 07-Jul-1993 0909 -0400" <[email-masked]>
Date: Wed, 7 Jul 93 09:08:04 EDT

Just to kick this off, I'd like peoples opinion on just exactly the best way
to handle SDLC specifically: maybe this is simple-minded, but I have been
assuming that the way to do this is to assign a MAC Address & SAP to each
SDLC station (which means that for an SDLC-to-SDLC type connection, two MAC
Addresses/SAP pairs are assigned).

The definition of an SDLC station in the router to which it is directly attached
would then contain the MAC Address/SAP for that station, and optionally the
MAC Address/SAP of the system to which it is defined to be connected - if the
MAC Addr/SAP of the other station is not defined, then communication can not
be initiated by that SDLC station.

For example (SAPs left off for clarity):

                          +------+
              +------+   /        \   +------+
    +----+    |Router|  /   IP     \  |Router|    +---+
    | 20 |----|  A   |-+  Network   +-|  B   |----|NCP|
    +----+    |      |  \          /  |      |    +---+
              +------+   \        /   +------+
                          +------+
        Local MAC Addr=1                 Local MAC Addr=2
        Dest  MAC Addr=2                 Dest  MAC Addr=1

If either Router did not have the destination defined, then it could not 
initiate CANUREACH processing to find the destination, and frames received 
from the attached SDLC station would simply be dropped.

This exact same approach also works unchanged (I think!) for the SDLC-to-LLC 
case.

However, this all seems too simple and obvious - I must be missing something ;-)

Simon

PS: Regarding adding QLLC to the list of possibilities - I have to question
	the real value of this: can anyone really justify it (other than for
	completeness?) Also, if we do decide to add QLLC, then we should
	presumably add all combinations, including QLLC-to-QLLC which was not
	listed in Bernie's message

(**************************************************************************)

From: [email-masked] (PNGacek)
Date: Wed, 07 Jul 93 13:37:44 MDT
Cc: [email-masked]
Status: R

Alan

It is probably worthwhile collecting together everything exchanged prior 
to the siglets. Something along the lines of what Shanon did in the flow 
control siglet.

We should make the RFC as DLC independent as we can. It should cover all 
your permutations, QLLC as well and include channel (I think we agreed 
that the channel discussion finds its way into the Connect Sig).

PU1 support is only really feasible for SDLC end to end connectivity. It 
gets a lot more difficult when going from one DLC to another.

Good job on putting the agenda together - we really have got a lot to do!

Regards Paul

(**************************************************************************)

Date: Thu, 08 Jul 93 09:27:13 PDT
From: [email-masked]
Status: R

Fellow Connect/Disconnect Working Group Members:

    I like the schedule Alan has put together.  It is a very ambitious 
    schedule but let's try to make it.

    Prior to the DLSw SIG meeting in June, I did done some analysis of the
    DLSw flows that the current RFC describes.  I laid them out in a MacDraw
    document and gave a copy to Alan Bartky for initial review (and airplane
    reading :-) at the conclusion of the AIW.  I also did a MacDraw version
    of the DLSw finite state machine.  These documents represent my 
    interpretation of the RFC and are therefore subject to error.

    I will give the PostScript version of these files to Alan over the
    weekend or early next week to place into the ibmstandards
    repository.  For the sake of email discussion, I also intend to do
    stick-man versions of the flows (but not the FSM).  Last of all, I
    intend to provide the flows for cisco's STUN since it has some of
    the properties that I think are desireable for the
    Connect/Disconnect working group and will provide something to throw
    darts at.

    So, here's what I intend to give to Alan either this weekend or early
    next week (all in PostScript form):
	(1) a series of flow diagrams for RFC 1434
	(2) a more complete version of the FSM for RFC 1434
	(3) a series of flow diagrams for STUN.

    Also, in email in this mailgroup, I will present both of the above
    flow diagrams.

    My initial comments (and maybe something to think about over the weekend)
    are:
	(1) the current DLSw plays too active a role in the station-to-station
	    exchange:
	    (a) by not passing DLC events at Connect and Disconnect time
		end-to-end between the stations, you get:
		 (i) RNR at Connect time,
		(ii) a rather disorderly take-down sequence that is very
		    tightly dependent upon local LLC2 events.
	    (b) making NT 2.1 support very complex:
		 (i) with the current design, XID3 must be performed between
		     the switch and the end stations, not between end stations
	(2) the current DLSw is too loosely coupled with its DLC.

    Some comments:
       The RNR in (1.a.i) causes an Alert to be sent to NetView each time the
       switch-to-switch link comes up (if NCP is set up to do so).  I 
       know ... cisco used to do the same thing.  Our product that RNR'd the
       FEP was on the market for 1 1/2 yrs. before we hit it.  I guess the
       6611 hasn't hit it yet :-).

       The Disconnect sequence in (1.a.ii) will work for an ABM DLC but not
       for an NRM DLC.

       The lack of end station-to-end station Connection in (1.b.i) results in
       a requirement to put all of the XID3 FSMs (FSM_XID3_T2P1_NODE, 
       FSM_XID3_NEG_PROTOCOL, FSM_XID3_PRI_PROTOCOL, and FSM_XID3_SEC_PROTOCOL)
       into the switch.

       The loose coupling mentioned in (2) makes the end station-to-end station
       operations impossible.

    Thanks for listening.  Look for the postings next week.

Wayne

(**************************************************************************)

#####################
end collected mail:
#####################

Regards,
Alan